IEEE 1588 PTP is now the industry accepted packet-based standard for distributing timing information from a master to enable the clocks of distributed systems to be synchronized with high precision (accuracies in the nanosecond levels). It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible. Relying on GPS for clock synchronization is not always practical (e.g., a base station may be in a tunnel or a large indoor facility) or its acceptance in certain regions of the world may be hindered by policies based on the reasoning that GPS is American owned. Hence, transferring timing via packet transport is a relevant synchronization technique that must coexist and interoperate with all others. However, the challenge here is packet delay variation (PDV) which represents a considerable noise component in the clock recovery system.
The IEEE 1588 PTP standard defines a wide range of synchronization capabilities except the clock recovery mechanisms (servo algorithm, phase-locked loop (PLL), timers, etc.) to be used at the receiver (slave) to synchronize its local clock to the master. The last pieces are vendor and proprietary solutions and are often product differentiators.
The slave clock synchronization accuracy is heavily dependent upon how well the path delay experienced by the PTP message between master and slave is known. Any non-deterministic delays within this path will translate to an error in the time offset calculations, thus degrading the synchronization accuracy unless compensated for. The non-deterministic latency behavior on the path is a consequence of the resource contention and store and forward architecture of packet transport, which consequently decrease time synchronization accuracies. As described below, IEEE 1588 end-to-end (“E2E”) transparent clocks (“TCs”) measure and update for the device residence time (device transit time) in a field of the PTP message. These updates allow the slave clock to compensate for the variability that exists on the path when synchronizing its clock to the master clock.
Overview of IEEE 1588v2 PTP
The GrandMaster (GM) is the root timing reference in a domain and transmits synchronization information to the clocks residing in its domain. In IEEE 1588v2 PTP messages are categorized into event and general messages. All IEEE 1588 PTP messages have a common header. Event messages are timed messages in that an accurate timestamp is generated at both transmission and receipt of each message. Event messages have to be accurately timestamped since the accuracy in transmission and receipt timestamps directly affects clock distribution accuracy. A timestamp event is generated at the time of transmission and reception of any event message. General messages are not required to be timestamped. The set of event messages consists of Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp. The set of general messages consists of Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management, and Signaling.
IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay-Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay-Resp).
The Sync, Delay_Req, Follow_Up, and Delay_Resp messages are used to generate and communicate the timing information needed to synchronize ordinary and boundary clocks (see description below) using the delay request-response mechanism. A Sync message is transmitted by a master to its slaves and either contains the exact time of its transmission or is followed by a Follow_Up message containing this time. In a two-step ordinary or boundary clock, the Follow_Up message communicates the value of the departure timestamp for a particular Sync message. A Delay_Req message is a request for the receiving node to return the time at which the Delay_Req message was received, using a Delay_Resp message.
The basic pattern of synchronization message exchanges for the one-step and two-step clocks are illustrated in FIG. 1 and FIG. 2, respectively. The message exchange pattern for the two-step clock can be explained as follows. The master 1 sends a Sync message to the slave 3 over network 2 and notes the time T1 at which it was sent. The slave 3 receives the Sync message and notes the time of reception T2. The master 1 conveys to the slave the timestamp T1 by one of two ways: 1) Embedding the timestamp T1 in the Sync message. This requires some sort of hardware processing (i.e., hardware timestamping) for highest accuracy and precision. 2) Embedding the timestamp T1 in a Follow_Up message. Next, the slave sends a Delay_Req message to the master and notes the time T3 at which it was sent. The master 1 receives the Delay_Req message and notes the time of reception T4. The master 1 conveys to the slave 3 the timestamp T4 by embedding it in a Delay_Resp message.
At the end of this PTP messages exchange, the slave 3 possesses all four timestamps {T1, T2, T3, T4}. These timestamps may be used to compute the offset of the slave's clock 5 with respect to the master's clock 4 and the mean propagation time of messages between the two clocks. The computation of offset and propagation time often assumes that the master-to-slave and slave-to-master propagation times are equal, i.e. a symmetrical communication path.
IEEE 1588 ordinary clocks and boundary clocks configured for the delay request-response mechanism use the following event messages to generate and communicate timing information—Sync, Delay_Req, Follow_Up, Delay_Resp. The delay request-response mechanism is used to measure the path delay between a master and an ordinary or boundary clock. Peer-to-peer transparent clocks use a similar mechanism called the peer delay mechanism but with different PTP messages.
Path Delay Measurements and Time Synchronization
IEEE 1588 PTP requires an accurate measurement of the communication path delay between the time server (master) 1 and the client (slave) 3 for clock synchronization. PTP measures the exact message transmit time and receive times and uses these times to calculate the communication path delay and clock offset. This delay measurement principle determines path delay between devices on the network and the local clocks are adjusted for this delay using the series of messages sent between masters 1 and slaves 3 (FIG. 1 and FIG. 2). The one-way delay time is calculated by averaging the path delay of the transmit and receive messages. This calculation assumes a symmetrical communication path over the network 2; however, packet networks do not necessarily have symmetrical communication paths, due to the buffering process in the network nodes (resulting in asymmetrical packet delay times). To address this, PTP provides a method, using transparent clock devices (implemented in switches and routers), to measure and account for the delay experienced by PTP messages in a time-interval field in the PTPmessages. This setup makes the switches and routers temporarily transparent (from a synchronization point) to the master 1 and slave 3 nodes on the network.
Transparent Clocks
The processing and buffering of packets 21 in network devices (switches, routers, etc.) introduce variations in the time latency of packets 21 traversing the packet network 2 as illustrated in FIG. 3 and FIG. 4. The variations in these delays means that the assumption that packet delay is the same in each direction is invalid, thus rendering the path delay calculations of PTP inaccurate. This issue can been addressed with the use of boundary clocks and transparent clocks.
A transparent clock (TC) does not act as a master or slave, but instead bridges these two and forwards PTP event messages and provides corrections for the residence time across the bridge. Residence time is the delay between the reception and transmission of a PTP message through a transparent clock device. These delays must be fully accounted for in the slave time offset correction. The role of transparent clocks in a PTP network is to determine certain path delay parameters and update a time-interval field (the correction field) that is part of the PTP event message header. This update allows the terminating clock to compensate for switch delays when synchronizing it clock to the master. There are two types of transparent clocks (End-to-End TCs and Peer-to-Peer TCs) but this work deals only with the E2E TC.
End-to-End (E2E) Transparent Clock
This is a multi-port device that is not a master or slave but a bridge between the two. This clock measures the message transit time (also known as resident time) in the device for (PTP event) Sync and Delay_Request messages as illustrated in FIG. 5. This measured transit time is added to the correction field in the corresponding messages:                The measured transit time of a Sync message is added to the correction field of the corresponding Sync or the Follow_Up message. In the one-step mode the residence time is added to the correction field of the Sync message; in the two-step mode the residence time is added to the correction field of the Follow_Up message.        The measured transit time of a Delay_Request message is added to the correction field of the corresponding Delay_Response message.        
E2E TC devices 6 measure the delay the PTP packet resides in the TC device and increment the correction field in the PTP header as illustrated in FIG. 6. A PTP message arriving at the ingress port 61 is detected and timestamped by the local clock 62. The Correction Field of the arriving PTP message is read out. When the PTP message reaches the egress port 63 of the TC, an egress timestamp is produced by the local clock 62. The TC calculates the difference between the ingress timestamp and the egress timestamp as the residence time in the TC. The Correction Field is then updated by adding the residence time in the TC to the existing value of the Correction Field in the outgoing PTP message.
FIG. 7 shows the flow of PTP messages through an example network of E2E TC devices. The correction field ends up containing the sum of all the residence times that a Sync or Delay_Request message has encountered on its way through all E2E-TC network elements on the path. By doing so, the slave clock or boundary clock further down the line can determine how long the PTP packet resided in the TC devices before it. The slave clock can then use the residence times accumulated in the correction field to mitigate the effects of PDV. This information is used by the slave when determining the offset between the slave's and the master's time. E2E transparent clocks do not provide correction for the propagation delay of the link itself between devices; only P2P TCs support this.
A one-step E2E TC updates for switch delay in Sync and Delay-Req messages as they pass through the switch while a two-step TC updates a field in the non time-critical general message (Follow_Up and Delay_Resp).
The process in FIG. 7 continues hop by hop (where N is the number of hops or links), and the Follow-Up (two-step mode), Sync (one-step mode) or Delay_Req (delay request-response mechanism) messages maintain a running total of the residence times; resulting in a grand total delay value from master to slave. Upon receipt of the final message, the slave device calculates its offset using the total residence time which is accumulated in the correction field as follows:
      total_residence    ⁢    _time    =            ∑              i        =        1                    N        -        1              ⁢                  ⁢          r      i      
The present invention aims to provide methods and devices which improve on the estimations of skew and offset of a slave clock where timing messages have passed through one or more transparent clocks on the path from the master to the slave.